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Bridge for CAN to TCP/IP Connection 
Background of the Invention 

1. Technical Field 

The present invention pertains to the field of network 
communication. More particularly, the present invention 
pertains to providing for communication between a controller 
area network (CAN) and a network implementing transmission 
control protocol/ Internet protocol (TCP/IP) , such as the 
Internet or an Ethernet. 

2. Description of Related Art 

A recent innovation in local area networks is the 
Control Area Network (CAN) standard, the basic level of which 
is identified in ISO 11898 and ISO 11519-1. The CAN standard 
was originally developed to specify distributed real-time 
control system requirements in automotive applications. An 
implementation according to the CAN standard is a real-time, 
distributed control system including different electronic 
components that communicate with each other not by signals 
carried by dedicated wires, but by signals conveyed by a 
linear bus according to the CAN protocol. Manufacturers such 
as Intel, Phillips, National Semiconductor, Nippon Electric 
Company, Siemens and Motorola provide very low cost CAN chips 
that conform to the protocol. The use of CAN technology has 
been extended to other custom applications, including 
industrial control applications. 

As shown in Fig. 1, a CAN-type network 11a provides for 
communication of pre-determined messages between stations 12a 
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(nodes of the CAN network, each of which are a control • unit ) 
interconnected in a linear bus structure by a CAN bus 14a. 
Each CAN station is the peer of every other station. Instead 
of addressing a message to another station by indicating the 
5 other station, a transmitting station indicates to all other 

stations the content of the message using an identifier 
provided with the message. In such content -based addressing, 
each message is broadcast' to all other, receiving stations, 
and each receiving station discards the message unless the 
10 message is on a pre-determined acceptance list for the 

receiver . 

There are now two versions of CAN, differing in the 
length of the identifier. A CAN implementation according to 
the CAN specification, part A, uses an 11-bit identifier. 
15 One according to the CAN specification, part B, uses a 29-bit 

identifier. See CAN Specification, Version 2.0 t by Robert 
Bosch GmbH, Postfach 50, D-7000 Stuttgart 1. 

Any station of a CAN network can use the CAN bus to 
transmit (broadcast) a message when the bus is unoccupied. 

20 While transmitting a message, a station monitors the bus for 

an indication that another station is also attempting to 
transmit a message. If another station is also attempting to 
use the bus, the contention for the bus is arbitrated using a 
scheme in which each message is pre-assigned a priority that 

25 accompanies the message. 

Message transfer in a CAN-type network is achieved using 
four types of frames. A data frame, as shown in Fig. 2, 
conveys data from a transmitter station to receiver stations, 
and has an identifier (of different length depending on the 

30 version of CAN, as described above) that indicates the type 
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of message, i.e. its content, used for content-addressing. A 
remote frame, as shown in Fig. 3, conveys a request for a 
data frame having an identifier that is the same as used in 
the remote frame. A remoter frame uses a remote transmission 
request (RTR) bit to identify itself, i.e. to indicate that 
it is a request for a CAN message. An error frame, as shown 
in Fig. 4, is transmitted by any station when the station 
detects a communication (bus) error, i.e. when the station 
receives a message but the cyclic redundancy check (CRC) for 
the message fails. An overload frame (not shown), is used to 
provide extra delay between data frames or remote frames, a 
delay that is in addition to the interfame spacing (Fig. 2). 

Various application layers have been developed with 
specifications specifically oriented to industrial and 
process control applications, control networks for heavy duty 
trucks and buses, distributed control systems and control 
networks for cars. However, all of these systems are limited 
to inter-node communication, and will not support 
communicating with nodes across an intervening network using 
a different protocol, such as TCP/IP, which is used for 
communication on the Internet. 

What is needed is a device that enables communication 
between stations of two different CAN-type networks 
interconnected by an intervening network, and especially an 
intervening network using TCP/IP, such as the Internet. Such 
a device would have to overcome the difficulty that a TCP/IP 
network uses physical addressing, while a CAN network uses 
content -based addressing, as indicated above. 

What is also needed is a way to view the content of 
messages being communicated in a CAN-type network using a 
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remote computer interconnected to the CAN-type network- via an 
intervening network using TCP/IP, such as the Internet. This 
would allow both monitoring a CAN-type network and also 
diagnosing problems for the CAN-type network, all from a 
5 remote location. 

Summary Of The Invention 

Accordingly, the present invention provides a method and 
corresponding apparatus for communicating a controller area 
network (CAN) message between a sending node, attached to a 

10 sending CAN network, and a receiving node; where the sending 

and receiving nodes are interconnected by a network 
communicating according to transmission control protocol/ 
Internet protocol (TCP/IP) ; where the CAN message includes a 
CAN message payload, which in turn includes an identifier 

15 field, intended to identify the content of the CAN message, 

based on a pre-determined identifier-content correspondence 
that is CAN-network-dependent or, more generally, node- 
dependent, a remote transmission request bit, a control 
field, and a data field, if any; and where the communicating 

20 is according to TCP/IP performed by transmitting TCP/IP 

frames, including a header, a footer, and a TCP/IP data 
field. The invention provides for having the sending node 
extract the CAN message payload from the CAN message; having 
the sending node embed the CAN message payload in the TCP/IP 

25 frame as the TCP/IP data field of the TCP/IP frame; having 

the sending node refer to a routing form to determine the 
address on the TCP/IP network of the receiving node; and 
having the sending node transmit the TCP/IP frame over the 
TCP/IP network using the address for the receiving node from 

3 0 the routing form. 
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in a further aspect of the invention, the receiving node 
extracts the CAN message payload from the TCP/IP frame; 
alters the identifier of the CAN message payload, as needed, 
so as to correspond to the CAN message content at the 
receiving node, the altering performed by reference to a 
mapping relating identifiers according to their usage at 
different network addresses,- and, if the receiving node is 
attached (directly connected) to a CAN network, having the 
receiving node broadcast the CAN message on the CAN network 
to which it is directly connected. if the receiving node 
hosts a browser, there is no broadcasting of the received CAN 
message payload, but only a displaying of the CAN message by 
the browser for examination by the user of the browser. 

Brief Description op the Dpawth^g 

The above and other objects, features and advantages of 
the invention will become apparent from a consideration of 
the subsequent detailed description presented in connection 
with accompanying drawings, in which: 

Fig. 1 is a block diagram showing the interconnection by 
a TCP/IP network of a CAN-type network with both another 
CAN-type network and also with a browser, according to the 
present invention; and 

Fig. 2 is a data structure diagram for a CAN data frame; 

Fig - 3 is a data structure diagram for a CAN remote 
25 frame; 

Fig. 4 is a data structure diagram for a CAN error 
frame; 
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Fig. 5 is a data structure diagram showing a CAN message 
included in a TCP/IP frame, according to the present 
invention; 

Fig. 6 is a flow chart/ task allocation diagram, 
5 according to the present invention, for transmitting a CAN 

message over a TCP/IP network; and 

Fig. 7 is a flow chart/ task allocation diagram, 
according to the present invention, for receiving a CAN 
message over a TCP/IP network. 

10 Best Mode For Carrying Out The Invention 

The preferred embodiment will now be described in the 
particular application where controller area network (CAN) 
messages are provided over the Internet. The Internet is 
here used as one example of a network communicating according 
15 to transmission control protocol/ Internet protocol (TCP/IP) . 

It is be understood that the present invention is directed to 
the communication of CAN messages over any network using 
TCP/IP, such as any Ethernet, not only the Internet. 

Referring now to Fig. 1, a bridge 10a for connecting a 
20 controller area network (CAN) 11a to an Internet connection 

16, which requires transmission control protocol/ Internet 
protocol (TCP/IP) , is shown as including a local CAN 
controller 21 for communicating over the CAN network 11a; 
TCP/IP protocol utility 23 for communicating over the 
25 Internet via the Internet connection 16; and an interfacing 

application 22 for converting CAN messages to a form suitable 
for communicating over the Internet, i.e. to a form according 
to TCP/IP, and also for converting Internet communications to 
a form suitable for communication over a CAN network, i.e. to 
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a form according lo one or m o£ 

-sage typ es. The CM „ et „ ork ua inciydes cm stac 

communicating via a raw k„ „ , 

g a CAN bus 14a, through which the bridge 10a 

also communicates with the CAN stations 12a. 

CAN ne S t n V eferrin9 '° ^ 3 ^ »« * «»t 

- networ, lla , can transmit< via . ^ ^ _ 

the present invention, a message that is on an , 
i • . - y c ls on an acceptance 

l-t of a CAN station 24 in a second CAN network llb 
interconnected „ ith tha first CM by ^ ^ 

Por this, tha CAN station „ of the seoond CAN „et„o rk „ b 
depends on a second bridge 10b. 

Besides being able to transmit a message that is 
reserved by a CAN station 24 of a second CAN network ub . . 
CAN statron 12 a of the first CAN network lla can transit a 
-sage so that is viewed b y a browser communicating over the 
internet via the internet connection 1 6 . Por this , ^ 
browser 18 relies on the services of the bridge XOa to 
convert the CAN message to a form suitable for TCP/JP 
communication. 

Referring now to Pig. s , according to ^ 
embodiment, a CAN message p. y ,oad, i.e. a CAN message less 

ACKte'^b^" US aCta °" 1 — " «*» "^ds ( the 

ACK f 16 ld bemg need to signs! to a sending station when , 

CAN measag. is received without error, . is embedded in , 

TCP/XP data fierd of a TCP /IP f ra me. A TCP/XP data field can 

he up to several kilob yt ee in Xength, compared to „ bytes as 

he maximum iengtb of a CAN message pa yl oad. In some aspects 

o the present invention, this disparity is taken advantage 

Of by embedding more than one CAN message pa yl oad in a TCP/XP 

frame. In the preferred embodiment, if the bridge 10a is 
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embedding a first CAN message in a TCP/IP frame, and a- second 
CAN message (for the same destination) is detected before a 
predetermined time interval elapses, the interfacing 
application will arrange to have the second CAN message 
5 payload added to the same TCP/IP data field, and so on, as 

described below. The predetermined waiting time is typically 
a second, but is sometimes as much as 5 seconds. 

According to the preferred embodiment of the present 
invention, the only two CAN message types that are embedded 

10 in a TCP/IP frame are a CAN data frame and a CAN remote 

frame. The CAN error frame is not needed because when a 
local station 12a broadcasts a CAN message and the local CAN 
controller 21 receives the CAN message, the local CAN 
controller 21 will signal (on the CAN bus 14a) any error in 

15 communication over the CAN bus 14a. And when a CAN message 

is transmitted by the bridge 10a over the Internet, the 
Internet TCP/IP provides for error detection and correction. 
Finally, if a message is intended for a CAN station 12b of 
the second CAN network lib, the bridge 10b attached to the 

20 CAN bus 14b for the second network extracts the CAN message 

from the TCP/IP data frame, constructs a CAN data frame or 
CAN remote frame (depending simply on whether the CAN message 
contains data) , and broadcasts the CAN message on the CAN bus 
14b for the second CAN network lib. From that point on, the 

25 CAN protocol for error detection and correction becomes 

effective. Thus it is unnecessary for the bridge 10a to 
include either a CRC field or an ACK field in a TCP/IP data 
frame when communicating a CAN message over the Internet. 

Referring again to Fig. 1, the local CAN controller 21 
30 of the bridge 10a, which is built around a standard CAN chip, 
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e-9. the SJA l000 , inter£aces ^ ^ 

networ* l!a. In this inter£acing , the lQcai _ t 

21 provides for oronpr K-if- • 

„ . ""-timing, and performs bit encoding 

d s y nchro„ 12 atio„. Ss the interface ^ ^ ^ ^ 

, 1" ^ e "° r £ — * — ° £ Emitting 

— — thac is not properly received by one ^ 

CAN stations on the CAN network u, In aMHi ^ ss 

mentioned above it- c ^ t 

«. « Signals an error in communication when it 
receives a CAN messaqe over t-ho ™» 
10 the CRC fails. ^ £ ~ ^ 

Finally, the local CAN controller 21 has, in the 
Preferred embodiment, its own acceptance l ist , and it 

acknowledges successful receipt of all can m * 

tL or ali CAN messages on that 
acceptance list. Such a Hat- ^ , ■ 
15 llSt 13 Used ln "se of some CAN 

messages being intended for CAN stations of another CAN 
network, such as the second CAN network llbf with which 
communication is through the bridge 10a and over the 
Internet . 

The bridge 10a, including the local CAN controller 2! 
is boated by a colter .not shown, , which in the preferred 

7"" ^ inter " al " '« —eating 

between varrous controllers, such as between the local CAN 

controller „ and the CPO «„ot shown, of the computer. The 
local CAN controller is f„v „ 

S ' f ° r "•'""Pie. a card in an ISA bus 
and has an assigned I/O base address. It uses a first-in- 
fi— out ,„ ro , bu££er 24 for storing ^ _ sag ^ ^ 

communicates with modules executing in th , CPD of the 
computer b y polling or b y interrupts. Por example, tor the 
local CAN controller 21 , in case of a computer using DOS or a 



-9- 



WO 01/45348 



PCT/US00/33187 



Windows operating system, a so-called ISACAN-PC card, ■ 
available from Hitex-Systementwicklung GmbH, could be used. 

Where the local CAN controller 21 interfaces the bridge 
10a to the CAN network 11a, the TCP/IP protocol utility 23 
5 interfaces the bridge 10a to the TCP/IP connection over the 

Internet 16. In the preferred embodiment, the TCP/IP 
protocol utility 23, executing in the CPU of the computer 
hosting the bridge, performs Internet communication in the 
same way as a standard Internet server. Thus, to the 

10 Internet, the bridge 10a appears to be an Internet server. 

On the Internet side of the TCP/IP protocol utility, data 
being communicated is in the form of packets, according to 
TCP/IP. On the interfacing application 22 side, data being 
communicated is in the form of files according to the 

15 operating system used by the bridge 10a. The operating 

system is, in the preferred embodiment, LINEX. 

The interfacing application 22 is what provides the 
conversion between TCP/IP and CAN message protocol. It 
executes in the CPU of the computer hosting the bridge 10a, 
20 along with the TCP/IP protocol utility 23. The interfacing 

application 22 has tasks to perform whenever the bridge 
receives a CAN message either over the Internet or from its 
directly attached CAN network 11a. 

Referring now to both Fig. 1 and Fig. 6, when, a CAN 
25 message is to be transmitted from the first CAN network 11a 

over the Internet via the bridge 10a, the CAN message is 
received by the local CAN controller 21 of the bridge 10a, 
because the CAN message is on an acceptance list of the local 
CAN controller, as described above, and placed in the FIFO 
30 buffer 24, preferably only the payload, i.e. the parts of the 
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CAN message that are tc be embedded in a TCP/IP data f rame 
namely the arbitration field, the control field, and the data 
field, if any (none fox a CAN remote frame). Then the local 

CAN controller 21 notifies t-ho e 

notities the interfacing application 22 of 

the CAN message by sett inn -.'^f.^ 

a y setting an interrupt, in the preferred 

embodiment, or when polled by the interfacing application 22 
The interfacing application then acquires the CAN message 
from the FIFO buffer 24 of the local CAN controller 21. 

Next, the interfacing application 22 must determine how 
to address the CAN message for Internet communication. For 
this, it uses a routing form indicating where to send each 
CAN message it acquires from the local CAN controller 21, 

based on the identifier r>f f h n pam 

ntitier of the CAN message. The routing form 

indicates each other CAN network, interconnected with the 
first by the Internet, to which a CAN message is to be sent 
based on the identifier of the CAN message used in the first 
local CAN network. 



^^■ovT."^/'^"^ in - rf a ci „ g application when sending a CAN 



Identifier 
(in origin CAN network) 


Internet address 
of recipient 


ld-CAN-A-xl 


111. 111. 111. Ill 




222.222.222.222 




333.333.333.333 




444.444.444.444 


id-CAN-A-x2 


111.111.111.111 


id-CAN-A-x3 


444.444.444.444 


id-CAN-A-x4 


111.111.111.111 



Table 1 illustrates the routing form used by the 
interfacing application 22 for the bridge 12a in sending a 
CAN message from the f irst CAN network lla over the Internet 
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to either another CAN network lib or to a browser 18. -The 
identifiers in the table (not the actual mapping) are 
symbolic. Thus, id-CAN-A-xl represents the identifier of a 
message xl in CAN network A, (the designator xl indicating, 
5 symbolically, the message content, so that e.g. id-CAN-A-xl 

and id-CAN-B-xl are two different identifiers for the same 
message content) . The actual identifier of course is 
different- The table indicates that the routing used by the 
interfacing application will send to four Internet addresses 
10 the message from CAN network A with identifier id-CAN-A-xl, 

the first Internet address being 111.111.111.111 (or an 
equivalent domain name), and so on. 

With a list of recipients prepared, the interfacing 
application 22 creates a new file containing the CAN message 

15 payload, and notifies the TCP/IP protocol utility 23 of the 

new file and of each recipient address (on the TCP/IP 
network) in turn. For each recipient provided, the TCP/IP 
protocol utility 23 then places the content of the new file 
in a TCP/IP data frame and transmits it over the Internet, 

20 per each address provided by the interfacing application 22. 

In the preferred embodiment, as mentioned above, the 
bridge 10a may place more than one CAN message payload in a 
TCP/IP data frame. For this, the interfacing application 22 
will wait a predetermined time before saving the new file 
25 with the first CAN message payload, in case other CAN 

messages are provided by the local CAN controller 21 for any 
of the same destinations as for the first CAN message. 

Referring now to Fig. 7, a bridge according to the 
present invention is shown acting as a receiving node, 
30 receiving a CAN message over the Internet, the CAN message 
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having been provided by . bridge ^ ^ 

invention actin 9 as a sending node. When a bridge 10a 
receives a CAN message pavload embedded in a TCP/IP data 
frame from a remote CAN network lib, lt extracts th<j CM 
message payXoad. saving it in , neu fUe Then ^ 
protocol utility 23 notifies the interfacing application 22 
Of the newly created file, identifying the file by name and 
location on the host computer, and provides the interfacing 
application 22 with the Internet address of the sender (the 
sender being a bridge connecting a remote CAN network to the 
Internet) . 

upon receiving the notification from the TCP/IP prot ocol 
utility 23. the interfacing application 22 extracts the CAN 
message payload. with an arbitration field inciuding an 
identifier appropriate to the sending, remote CAN network 
and associates the CAN message with the internet address of 
the sending, remote CAN network, as provided by the TCP/IP 
protocol utility 23. The interfacing application 22 then 
uses a mapping ,„ £or eJtample .„ ^ ^ ^ 

identifier in the local CAN network corresponds to the 
identifier in the new file ,i. e . to the identifier used by 
the remote, sending CAN network,, given the Internet address 
of the sender. Using an interrupt or a polling pr0 oess to 
9 ain access to the pipo buffer 2, o, the local CAN controller 
21. the interfacing application 22 then pieces in the FIFO 
buffer 24 the CAN message payload, with the sender's 
identifier replaced by the corresponding identifier for the 
local CAN network 10a. 
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Table 2. Mapping used by interfacing application when receiving a CAN 
message over a TCP/IP network. 



Identifier 
used by sender 


Internet address 
of sender 


Identifier 

lu xjcr uocu uy icLipi cuC 


id- CAN - B - x 1 


"ITT 1 1 1 1 1 1 111 

in . in. hi . in 






222 . 222 . 222 . 222 




id-CAN-D-xl 


333.333.333.333 




id-CAN-B-x2 


111.111.111.111 


id-CAN-A-x2 


id-CAN-C-x2 


222.222.222.222 




id-CAN-D-x2 


333.333.333.333 




id-CAN-E-x3 


555.555.555.555 


id-CAN-A-x3 


id-CAN-B-x4 


111.111.111.111 


id-CAN-A-x4 



In response to the interrupt set by the interfacing 
application 22, the local CAN controller 21 waits a pre- 
5 determined time sufficient for the interfacing application 22 

to place the CAN message payload in the FIFO buffer 24, and 
then retrieves the CAN message payload, provides the 
additional CAN message fields, including the CRC and ACK 
fields, required to build a complete CAN message (CAN data 
10 frame or CAN remote frame) , and transmits (broadcasts) the 

complete CAN message over the local CAN network 11a. 

As mentioned above, the present invention is intended to 
comprehend having a node hosting only a browser (not a bridge 
according to the present invention) receive a CAN message 

15 provided by a bridge acting as a sending node, in which case 

the browser, acting as the receiving node, in some 
embodiments, simply extracts the CAN message payload from the 
TCP/IP frame and presents the CAN message payload for 
examination by the user of the browser. In the preferred 

20 embodiment, however, the browser-hosting receiving node also 

uses a mapping to alter the identifier in the received CAN 
message so as to conform to identifier-content usage at the 

-14- 
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receiving node. Che altering bas ed on the Internet 
the sending node. 

It is to be understood that the above-described 
arrangements are only iUustrative of the application of the 
principle of the present invention. i„ particular as 
explained above, the present invention is not United to use 
in sending CAN mess.ges over che Internet; , ( 

sending CAH massages over any network in which communication 
ts according to TCP/IP, such as any Ethernet ■ Jn 
numerous modifications and alternative arrangements may be' 
devised by those skilled in the art without departing from 
the spirit and scope of the present invention, and the 
appended claims are intended to cover such modifications and 
arrangements . 
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What is claimed is: 

1. A method of communicating a controller area network (CAN) 
message between a sending node, attached to a sending CAN 
network, and a receiving node, the sending and receiving 
5 nodes interconnected by a network communicating according to 

transmission control protocol/ Internet protocol (TCP/IP) , 
the CAN message including: 

- a start of frame bit, 

- a CAN message payload, 

10 - a cyclic redundancy check field, 

- an acknowledgment field, and 

- an end of frame field; 

the CAN message payload including: 

- an identifier field, intended to identify the content 
15 of the CAN message, based on a pre-determined 

identifier-content correspondence that is node- 
dependent , 

- a remote transmission request bit, 

- a control field, and 

20 - an optional data field; 

the communicating according to TCP/IP performed by 
transmitting TCP/IP frames, including a header, a footer, and 
a TCP/IP data field; the method comprising the steps of: 

a) having the sending node extract the CAN message payload 
25 from the CAN message; 

b) having the sending node embed the CAN message payload 
in the TCP/IP frame as the TCP/IP data field of the 
TCP/IP frame; 

c) having the sending node refer to a routing form to 
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determine the address on the TCP /IP network of 6he 
receiving node; and 
-» having the sending node transit the TCP/XP frame over 

node from the routing form. 

2. The method of claim i , ,u~ 

claim l, wherein the receiving node is 

attached to a receiving CAN network an H ^ 

network, and the method further 

comprises the steps of: 

a) having the receiving node extract the CAN message 

payload from the TCP/IP frame; 
b, hav lng the receive node alter the identifier of the 
=» message p ayl0 ad, as needed, so as to correspond to 
the CAN message content in the receiving CAN network 
the altering performed by reference to a capping ' 
relating identifiers in different CAN networks, the 
different CAN networks being distinguished by their 
network addresses; and 
C having the receivi „ g node ^ ^ ^ 

the receiving CAN network. 

3. The method of claim „ herei „ the receiving ^ 
browser, and the method further comprises the steps of 
a) havrng the receiving node extract the CAN message 

payload from the TCP/IP frame; 
b, having the receiving node . dmtifier ^ 

CAN message payload. as needed, so as to correspond to 
the CAN message content at the receiving node , the 
altering performed by reference to a mapping relating 
identifiers based on the network address of the sending 
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4. An apparatus for sending a controller area network- (CAN) 
message from a sending node, attached to a sending CAN 
network, to a receiving node, the sending and receiving nodes 
interconnected by a network communicating according to 
transmission control protocol/ Internet protocol (TCP/IP) , 
the CAN message including: 

- a start of frame bit, 

- a CAN message payload, 

- a cyclic redundancy check field, 

- an acknowledgment field, and 

- an end of frame field; 

the CAN message payload including: 

- an identifier field, intended to identify the content 
of the CAN message, based on a pre-determined 
identifier- content correspondence that is node- 
dependent, 

- a remote transmission request bit, 

- a control field, and 

- a data field of variable length; 

the communicating according to TCP/IP performed by 
transmitting TCP/IP frames, including a header, a footer, and 
a TCP/IP data field; the apparatus comprising: 

a) a local CAN controller, responsive to the CAN message 
as broadcast over the sending CAN network, for 
extracting the CAN message payload from the CAN message 
and for saving the CAN message payload in a buffer; 

b) an interfacing application, responsive to the CAN 
message payload in the buffer, for embedding the CAN 
message payload in the TCP/IP frame as the TCP/IP data 
field of the TCP/IP frame, and for providing the 
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address on the TCP/IP network of the receiving node by 
referring to a routing form; and 
d) a TCP/IP protocol utility< ^^^^ ^ address ^ 

the receiving node and further responsive to the TCP/IP 
frame in which the CAN message payload is embedded for 
transmitting the TCP/IP frame over the TCP/IP network 
using the address for the receiving node determined 
from the routing form. 

5. An apparatus for receiving at a receiving node a 
controller area network (CAN) message sent from a sending 
node, the sending node attached to a sending CAN network the 
receiving node attached to a receiving CAN network, the 
sending and receiving nodes interconnected by a network 
communicating according to transmission control protocol/ 
internet protocol (TCP/IP) , the CAN message including: 

- a start of frame bit, 

- a CAN message payload, 

- a cyclic redundancy check field, 

- an acknowledgment field, and 

- an end of frame field; 

the CAN message payload including: 

- an identifier field, intended to identify the content 
of the CAN message, based on a pre-determined 
identifier-content correspondence for the CAN network 
in which the CAN message is being communicated, 

a remote transmission request bit, 

- a control field, and 

- an optional data field; 
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the communicating according to TCP/IP performed by 
transmitting TCP/IP frames, including a header, a footer, and 
a TCP/IP data field; the apparatus comprising: 

a) a TCP/IP protocol utility, responsive to the TCP/IP 

5 frame in which the CAN message payload is embedded, for 

extracting the CAN message payload from the TCP/IP 
frame, and for providing the network address of the 
sending node; 

b) an interfacing application, responsive to the CAN 

10 message payload extracted from the TCP/IP frame and to 

the network address of the sending node, for altering 
the identifier of the CAN message payload, as needed, 
so as to correspond to the CAN message content in the 
receiving CAN network, the altering performed by 

15 reference to a mapping relating identifiers in 

different CAN networks, the different CAN networks 
being distinguished by their TCP/IP network addresses, 
for providing the CAN message payload with the altered 
as needed identifier in a buffer; and 

20 c) a local CAN controller, responsive to the CAN message 

payload in the buffer, for augmenting the CAN message 
payload with additional fields as required to provide a 
complete CAN message, and for broadcasting the 
completed CAN message over receiving CAN network. 
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